feat(alterschema): add format_type_mismatch rule#696
Open
Vaibhav701161 wants to merge 3 commits intosourcemeta:mainfrom
Open
feat(alterschema): add format_type_mismatch rule#696Vaibhav701161 wants to merge 3 commits intosourcemeta:mainfrom
Vaibhav701161 wants to merge 3 commits intosourcemeta:mainfrom
Conversation
- port rule from core to Blaze alterschema module - align with Blaze architecture and conventions - add full test coverage across supported scenarios Signed-off-by: Vaibhav mittal <vaibhavmittal929@gmail.com>
- use walker metadata for keyword applicability - target the format keyword location only - decouple tests from unrelated trace ordering - restore minimal CMake diff Signed-off-by: Vaibhav mittal <vaibhavmittal929@gmail.com>
- revert rule logic to the original core condition - restore keyword targeting and vocabulary guard - remove Blaze-specific test helper indirection - match core trace expectations in all dialect tests Signed-off-by: Vaibhav mittal <vaibhavmittal929@gmail.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 8 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="test/alterschema/alterschema_lint_draft3_test.cc">
<violation number="1" location="test/alterschema/alterschema_lint_draft3_test.cc:1097">
P2: The test assumes only two diagnostics under `/additionalProperties`, but the nested `properties` keyword is also eligible for `non_applicable_type_specific_keywords` and may produce a third trace.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR introduces a new lint rule:
format_type_mismatchto the AlterSchema module in Blaze.The rule detects schemas where the
formatkeyword is used alongside a non-stringtype.{ "type": "integer", "format": "email" }In JSON Schema,
formatvalidation is defined for string instances. Using it with other types does not have any effect and is typically an authoring mistake.This rule highlights such cases to improve schema correctness and provide clearer diagnostics.
The rule emits a diagnostic when:
formatexiststypeexiststypeis a single string valuetypeis not"string"The diagnostic points to the
formatkeyword location.This rule is non auto-fixable because modifying either
typeorformatwould require assumptions about the author’s intent.Implementation
The rule follows the existing AlterSchema linter architecture in Blaze:
src/alterschema/linter/format_type_mismatch.hThe rule checks:
formatis defined and is a stringtypeis defined and is a stringtype != "string"If these conditions are met the rule returns:
Design Notes
This rule is designed to provide a more explicit diagnostic for misuse of the
formatkeyword.While similar cases may be implicitly handled by more generic rules (e.g., type-specific keyword validation), this rule focuses specifically on
formatto improve clarity and developer feedback.The rule intentionally skips cases where
typeis an array (e.g.,["string", "integer"]), sinceformatmay still apply when the instance is a string.The implementation aligns with existing Blaze conventions and does not introduce new abstractions or deviations from established patterns.
Tests
Tests were added following the existing AlterSchema testing patterns in Blaze.
The following scenarios are covered:
formatis used with non-string typestypeis"string"formatis missingtypeis missingtypeis an array including"string"properties,items, etc.)$refscenarios where applicableAll tests are aligned with Blaze test structure and conventions.
Notes